Nebula 2/Nebula Two.iso/SourceCode/MiscKit1.7.1/MiscKitArchive.mbox/mbox/[e-mail]_Mon Sep 13 12:25 MDT 1993.msg

Internet Message Format | 1994-10-30 | 11KB

Received: from yvax2.byu.edu by maine.et.byu.edu; Mon, 13 Sep 93 12:25:54 -0600
Return-Path: <[e-mail]>
Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.2-13 #4169) id
 <[e-mail]>; Mon, 13 Sep 1993 12:23:52 MDT
Received: from alaska.et.byu.edu by yvax.byu.edu (PMDF V4.2-13 #4169) id
 <[e-mail]>; Mon, 13 Sep 1993 12:23:47 MDT
Received: from yvax2.byu.edu by alaska.et.byu.edu; Mon, 13 Sep 93 12:24:02 -0600
Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.2-13 #4169) id
 <[e-mail]>; Mon, 13 Sep 1993 12:22:04 MDT
Received: from oregon.et.byu.edu by yvax.byu.edu (PMDF V4.2-13 #4169) id
 <[e-mail]>; Mon, 13 Sep 1993 12:22:00 MDT
Received: by oregon.et.byu.edu; Mon, 13 Sep 93 12:23:51 -0600
Date: Mon, 13 Sep 1993 12:23:51 -0600
From: [e-mail] (Don Yacktman)
Subject: Welcome to the MiscKit mailing list! (LONG)
To: [e-mail]
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7BIT
Status: RO



* Warning:  This message is very long.  Save it and read
it on your next coffee break, or two, or three, ...  :-)



Hello, and welcome to the MiscKit mailing list!

If you get this message, you're on the list.  Any
bad addresses on the list should cause mail to bounce
to me, but if you send a message and get a bounce,
do be sure to forward it to me so that I can fix
the problem.  (Send it to [e-mail])

Everything is now up and running, and should work just
fine.  As a reminder, messages to be distributed to
the entire list should be sent to [e-mail] and
any administrative requests should be sent to the
[e-mail] alias or to me directly.  (I'm
[e-mail]).  Please do not send administrative
requests to the list itself, as it clutters everyone's
mailboxes, something we can all live without.

One of the first things to be established is whether or
not NeXTMail messages should be allowed.  Most of the
people on the list can accept NeXTMail directly, but
there are several who cannot.  (Me, for instance.  I
have to save the message and run it through a decoder
in order to read it, which can be a bit of a pain.)
IMHO, the best way to handle this is to use ascii mail
message for all discussion, but use NeXTMail to send
pertinent attachments.  For those who do not have a
NeXTMail decoder, send me mail and I can show you just
how easy it is to decode... :-)  So, basically, no
NeXTMail unless it's got an attachment.  Any problems
with this?

Next, it is important to understand what the kit is,
what it isn't, and how contributions, etc., will be
managed.  Of course, all of this is up for discussion,
but I'll start with my perspective, and we can go
from there...

Originally, the MiscKit was a kit which I used in my
own projects.  I got tired of always including the
same objects in every project I started, so I built
a library and now I just include the library in PB,
and I'm done with it.  The idea here was that all the
classes in the MiscKit were classes which would be
used in every app I build.  For example, the String
and ExtendedApp classes are used in every app I write.

Since I found the kit useful, I released it publically
to save other people from having to take the time to
do everything I did.  Realizing that making the kit
utterly free would make it more useful, I also freed
up the license, and have now decided to accept new
contributions from the net at large.

This opens up several issues which need to be discussed:

(1)  I've been prefixing all the objects with "DAY", my
    initials, to avoid conflicts with other classes
    which might be used.  Obviously, with everyone
    contributing, this has to change.  So a new prefix
    needs to be selected.  Tomorrow I will post a
    list of suggestions which have already been made
    by several people, so let's hold the discussion
    on this one until then...but think of a few of
    your own in the meantime.

(2)  Licensing issues need to be dealt with.  I'm no lawyer
    by any stretch of the imagination, and we need to
    put a real license on the kit, at the very least
    to make sure that no one is held liable for vicious
    bugs... I do NOT want the GNU license, since using
    it would cause several people (primarily commercial
    software developers) to shy away from the kit, which
    is not what I want.  The spirit of the license, IMHO,
    should be that of free use.  The details that need
    to be decided upon are:

    a) If used in an app, credit should be given, somewhere,
    to the authors of the kit and a pointer to the location
    of the most recent source code should be given.  This
    will help people become aware of the kit and make it
    easily obtainable.  I don't think that inclusion of the
    source code should be necessary...that's too hard for
    commercial developers, and most customers couldn't care
    less about getting the source anyway.  A pointer to its
    location ought to be sufficient, I'd think.

    b) What restrictions on redistribution on CD-ROMs, etc.,
    ought to be placed?  I'd like to allow redistribution of
    only the complete source package.  Any modified versions
    should be clearly labelled as such.

    c) Should people who modify the source be requested to
    send modifications back to us?  I'd think so, but I would
    NOT require that subclasses be sent back--though they'd
    certainly be welcome.

    Those are the main issues, but I'm sure we'll come up
    with more.  The important thing here is to delineate a
    policy we're all comfortable with--and I lean towards
    keeping things as open as possible.  Once a policy is
    decided upon, it needs to be turned into something the
    vultures, er, lawyers can understand.

    One suggestion I have received on this is to take Larry
    Wall's freeware license and modify that; we'd need to
    get his permission first, though.

(3)  What should be allowed as a contribution to the kit?  This is
    asking more, what should the focus be?  The original focus
    was "objects that would be useful in every app I write."
    I think that might be too limiting.  So, then, how should
    this be adjusted?  I'm for accepting anything people are
    willing to contribute, but this leads to a problem.  If
    there is too much in the kit, when an app is linked against
    the kit, a lot of unused code might end up linked into the
    app.  The best solution to this is to split the MiscKit
    itself up into several smaller libraries.  (For example,
    there are several objects to deal with time, so make a
    "time" library for those, etc.)  Right now, the kit's not
    big enough to warrant a split, but the interest in this
    project -- and responses I've had -- suggest that it will
    be getting pretty big quite rapidly.

(4)  What do you have that you'd like to include in the kit?  Note
    that a contribution to the kit doesn't have to be a complete
    object.  Categories that extend AppKit objects would be
    really handy.  Also, bug fixes and extensions to existing
    objects would be nice.

(5)  How are contributors to be recognized?  A file in the root level
    of the kit distribution ought to be sufficient, but what
    information would you like to see in it?  Name, e-mail, and
    perhaps what you have contributed?

(6)  How is development to be controlled?  (ie. additions, changes,
    and bug reports/fixes)  For now, I see this as my responsibility
    since I started the whole thing, but it doesn't necessarily
    need to remain that way.  I'm a programmer, and not an
    administrator...but for now I think it would be best for
    me to handle this sort of thing.  Basically, I think bug
    reports ought to be directed to the list.  (Or, the author
    of the code which has the bug, if the contrib file has that
    much info, since the author would be most likely to be able
    to _find_ the problem and fix it...)  Changes and additions
    should be filtered through me.  I won't have time to do a
    complete testing/validation as I have other work to do too,
    but I can at least make sure that conflicting changes don't
    ruin some code somewhere.  As to things like modification of
    existing code, an individual ought to make sure that someone
    else isn't already working on that particular thing.  I can
    think of several ways to control this.  One is for me to
    play "Mr. intelligent RCS" and then an individual would first
    ask me if a particular project is available or already being
    done--and then I keep track of who's doing what.  A better
    approach IMHO is to distribute this, and let the original
    author of a particular object control development of that
    particular object.  (And then I'd handle coordinating who
    should develop which object.)  Two other possibilities.  Set
    up a "work in progress" file which lists available projects
    and who's currently working on them, or, two, use this alias
    to coordinate efforts.  I think perhaps the project file would
    be useful on the "who does which object" but too clunky for
    the individual changes to the object.  And using the list would
    likely generate far too much traffic.  Any suggestions as to
    how these issues ought to be handled, and any suggestions
    about the policies which should be adhered to, would be
    welcome here.  I want this to be a comfortable development
    environment.

    As a radical suggestion to how to handle this development,
    another thing that could be done is to set up a "manager"
    program that can act as coordinator.  It would be most
    useful as an e-mail address that you send mail to.  You send
    it mail to (1) add a project that could be worked on, (2)
    send in a bug report, which then becomes a project, (3)
    ask to work on a project--at which point it will tell you
    that either you have it, or who already has it, and (4)
    you can ask it to send you an index of all projects, or
    a detailed description of any project.  This software would
    sort of be an extension of a bug tracker, but could be a
    potentially useful way to manage a community project, and
    would remove a lot of the burden from the project manager.
    (I guess that's me for now.)  So, does anything like this
    exist for free?  Or, would someone like to write such a
    beast?  I think this one has potential...and could end up
    being useful for other people's projects as well!

Well, that covers a lot of the main questions that I think ought
to be considered.  If you have any suggestions for any of these
or have other pertinent questions, post them to [e-mail]
and we'll go from there!  (I suspect that the traffic will be
pretty heavy for the first week or two and then it should settle
down into a steady trickle...so brace yourself for the barrage. :)

Later,
[e-mail]                  Nepotism is a relative thing.



PS.  For the curious, there are nearly seventy addresses on the
list already, and some of them are used as distributions points
to further disseminate the traffic within a particular organization.
Welcome everybody, and let's have some fun!